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MAC address. Alternatively the header information for the data group packet consists of a conventional NABTS-dcfincd record header. 
The variablo-length data group packet is then encoded into one or more fixed-length VBI-compatible packets. Each VBI-compatible 
packet has the potential to store up to 28 bytes of data. The data group packet is partitioned and placed into the data blocks. 



FOR THE PURPOSES OF INFORMATION ONLY 



Codes used to identify States party to the PCT on the front pages of pamphlets publishing international applications under the PCT. 



AL 


Albmnia 


ES 


Spain 


LS 


Lesotho 


51 


Slovenia 


AM 


Aratcnia 


n 


Finland 


LT 


Lithuania 


SK 


Slovaki* 


AT 


Austria 


FR 


France 


LU 


Laxcmbourg 


SN 


Senega] 


AU 


AostraKa 


OA 


Gabon 


LV 


Latvia 


sz 


Swaziland 


AZ 


Azobaljan 


GB 


United Kingdom 


MC 


Monaco 


TD 


Chad 


BA 


BmnU and HerEegovina 


G£ 


Oeorgia 


MD 


Republic of Moldova 


TG 


Togo 


BB 


Bartkodos 


GH 


Ghana 


MG 


Madagascar 


TJ 


Tajikistan 


BB 


Belgium 


CN 


Guinea 


MK 


The former Yugoslav 


TM 


Turicmeniscan 


BF 


Burkina Faso 


GR 


Greece 




Repobtic of Macedonia 


TR 


Turicey 


BG 


Bulgaria 


HU 


Hungary 


ML 


Mali 


XT 


lYinidad and Tobago 


BJ 


Benin. 


IE 




NfN 


MongoKa 


UA 


Ukraine 


BR 


Bruil 


IL 


Israel 


MR 


Mauritania 


UG 


Uganda 


BY 


"Beltros 


IS 


Iceland 


MW 


MaUwi 


US 


United Stales of America 


CA 


Canada 


IT 


Italy 


MX 


Mexico 


UZ 


Uzbekistan 


CF 


Central African Republic 


JP 


Japan 


NE 


Niger 


VN 


Viet Nam 


CG 


Congo 


KE 


Kenya 


NL 


Netheriandi 


VU 


Yugoslavia 


CH 


SwitzerUnd 


KG 


Kyrgyzstin 


NO 


Norway 


zw 


Zimbabwe 


CI 


C6tc d'lvoire 


KP 


Democratic People's 


NZ 


New Zealand 






CM 


Camcnxm 




Republic of KonM 


PL 


Poland 






CN 


CJitna 


KR 


Republic of Korea 


FT 


Portugal 






cu 


Cuba 


KZ 


Kaxakstan 


RO 


Romania 






cz 


Czech Republic 


LC 


Saint L^cia 


KU 


Russian Federation 






DE 


Germ my 


LI 


Liechtenstein 


SD 


Siidan 






DK 


Denmaiic 


LK 


Sri t^lca 


SE 


Sweden 






EE 


Estonia 


LR 


Liberia 


SG 


Singapore 







wo 98/16066 



PCTAJS97/15853 



10 



Method for Sending Computer Network Data As Part Of 
Vertical Blanking Interval 



TFrHNTrAT. FIELD 

This invention relates to methods for sending computer network data, and 
particularly Internet Protocol (IP) data, as part of the Vertical Blanking Interval of a 
broadcast video signal (e.g., a conventional television signal). 



tt Aricr;ROTJND OF THE INVENTION 

Conventional broadcast television signals are transmitted in a data format that 
is used to construct individual television frames. Each frame contains video image 
data (i.e., pixel data) used to create images on the television screen and control 

15 information used to control the presentation of the image, such as synchronization 
and timing information. The Video Blanking Interval (VBI) is the upper 21 lines of a 
typical television frame. These VBI lines are not displayed on the television, but are 
instead used to carry the television control information. Up to ten VBI lines can be 
used for transmission of data separate from and in addition to the television image 

20 control information. Additionally, line 21 of the VBI is used for transmission of 
closed captioning information. 

A standard format for sending data as part of the VBI lines is specified by the 
Electronic Industries Association document EI A-5 1 6 (May, 1988): "JointfEtA/CVCC 
Recommended Practice for Teletext: North American Basic Teletext Specification 

25 (NABTS)." The NABTS specification defines a format for dividing lengthy streams 
of data into fixed-length data packets. It is these data packets that are encoded into 
the VBI and transmitted over the broadcast network. 
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Fig. 1 shows a VBI-compatible data packet 20 consisting of 33 eight-bit bytes. 
The VBI data packet 20 comprises a data block 22, which may be up to 28 bytes in 
length, and a five-byte prefix or header 24. The data block 22 varies in length 
depending upon the size of an optional suffix or trailer 26, which follows the data 
5 block. The trailer 26 can be 0, I, 2, or 28 bytes in length. Accordingly, the data 
block can be 0, 26, 27, or 28 bytes in length. Different encoders have different 
modes which dictate the length of the trailer 26 and hence, the length of the actual 
data stored in the data block 22. The optional trailer 26 provides room for specifying 
error detection or error detection and correction data to be used by receivers. The 

10 five-byte header 24 consists of three packet address bytes, one continuity index byte, 
and one packet structure byte. 

Present VBI encoding and decoding technology provides a convenient and 
reliable method for sending data as part of the VBI of a television signal. Today, the 
VBI is used for transmission of a number of forms of data, including stock quotes 

15 and weather data, for example. For a number of years, it was uncommon for users to 
view television on their computers. More recently, though, it has become more 
common for users to view television signals on their computers. An increasing 
nimiber of viewer/users is expected in the fiiture. With such convergence of 
television viewing and computer use, it is expected that viewers will want to be able 

20 to make use of the data transmitted in the VBI easily, especially on their computers. 
Unfortunately, most computer applications today are not configured to be compatible 
with the VBI data. To receive the VBI data, application. developers must specialize 
their products. This is particularly the case for developers building applications for a 
Windows®-based operating system manufactured and sold by Microsoft, as such 

25 applications must be configured to call specialized functions that are not a standard 
part of the Windows® operating system. 
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It would be beneficial to provide a more global approach to transmitting VBI 
data so that it can be easily used in computer applications without calling specialized 
functions. 

In the network environment, computer applications use standard sets of 
5 Application Programming Interfaces (APIs) to transmit and receive data over 
networks and over the Internet. For example, apphcations designed to run on 
Windows®-based operating systems employ a standard set of APIs that are defined 
in the Windows Sockets Specification, a well known specification. These APIs have 
been defined by industry committees and are widely in use. The Sockets APIs 

10 provide a network independent way to send and receive data, no matter what the 
underlying computer network (e.g., Ethernet, asynchronous transfer mode (ATM), 
satellite, etc.). Computer applications do not need to be specially written to receive 
data fi-om a particular network. Instead, a developer writes code for an application 
that interfaces to the Windows® Sockets API, enabling the application to send and 

15 receive data over a number of different networks supported by the computer's 
hardware. 

One common and widely used type of network data is called Internet Protocol 
(IP) data. IP data defines a standard format for carrying data over essentially any 
underlying network, including the Ethernet and the Internet. The IP standard defines 
20 a packet used to encapsulate the data, and IP data is always encapsulated in this 
packet, regardless of the transmission network. 

The inventor has conceived of a technique to repackage network data, such as 
IP data, into a VBI-compatible format which can - be transmitted as part of a 
traditional broadcast television signal. At the receiver, the network data is extracted 
25 firom the VBI signal and passed to the computer application through a standard set of 
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existing APIs, rather than through proprietary or non-standard functions known only 
to single monolithic client applications. 
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STnVfMARY OF THE TNVENTION 

One aspect of this invention concerns a method for encoding network data, 
such as Internet Protocol (IP) data, into a format for transmission as part of the 
Vertical Blanking Interval (VBI) of a broadcast video signal. This method includes 
5 configuring a network data packet having a data block and header information. As 
an example, an IP packet has a variable length data block and fixed length header 
information in the form of an EP header and a UDP (User Datagram Protocol) header. 

The network data packet is encoded into a variable-length data group packet, 
which is preferably an NABTS-compatible data group packet. The data group packet 

10 has a variable-length data block and header information. The network data packet is 
inserted into the data block of the data group packet. In one implementation, the 
header information for the data group packet includes a 2-byte type header which 
identifies a type of network data contained in the data block of the data group packet 
and a 6-byte reserved space header which is reserved for future definition by the 

15 developer. One potential use of the reserved space header is for a Media Access, 
Control (MAC) address, typically synonymous with physical address. The MAC 
address is normally used in reference to the low level hardware protocols used to 
access a particular network. In a second implementation, the header information for 
the data group packet consists of a conventional five-byte NABTS-compatible record 

20 header. 

Once the variable-length data group packet is constructed, it is encoded into 
one or more fixed-length VBI-compatible packets. These VBI-compatible packets 
are preferably the 33-bjrte packets defined at the network layer of the NABTS.^ , 
standard. Each VBI-compatible packet has the potential to store up to 28 bytes of 
25 data. The data group packet is partitioned and placed into the data blocks of the VBI- 
compatible packets. 
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Using this method, data received over a data network (i.e., Ethernet or 
Internet) is repackaged for broadcast as part of the VBI of a television signal. The 
packaged network data remains independent of the underlying network and can be 
easily extracted at the receiver for use by computer applications. 
5 According to another aspect, a method for decoding computer network data 

received as part of the VBI is described. The multiple fixed-length VBI-compatible 
packets are received at individual user-based receiving uiiits (i.e., television, set-top 
box, computer). The variable-length data group packet are reconstructed by stripping 
the header from the fixed-length VBI-compatible packets and combining the data 

10 payload of the VBI-compatible packets. The reconstructed data group packet has a 
header describing the type of network data and a data block containing the network 
data. The receiving unit reads the header and extracts the network data from the data 
block of the data group packet. 

In this manner, network data is transmitted over the VBI without losing its 

15 known format. A computer application can use standard APIs, such as those 
prescribed by the Windows Sockets Specification, to use the network data. By 
transmitting encapsulated network data in a VBI-compatible packet, content 
distributors will be able to support a wide new range of applications. Applications 
developers will find it easy to make use of the network data because it is available 

20 through standard interfaces with which they are already familiar. 



BRIEF DESCRIPTION OF THE DRAWINGS 

Fig. 1 is a diagrammatic illustration of a prior art packet structure constructed 
25 according to the North American Basic Teletext Specification (NABTS) standard. 

Fig. 2 is a diagrammatic illustration of a broadcast transmission system. 

0 
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Fig. 3 is a flow diagram of a method for sending network data over the 
broadcast transmission system. 

Fig. 4 is a diagrammatic illustration of a data transmission structure used to 
carry network data in a VBI-compatible packet according to a first implementation. 
5 Fig. 5 is a diagrammatic illustration of a data transmission structure used to 

carry network data in a VBI-compatible packet according to a second 
implementation. 

Fig. 6 is a block diagram of a receiving and decoding unit. 

10 

T>FTATT.ED DESCRIPTION OF THE PREFERRED EMBODIMENT 

The following discussion assumes that the reader is familiar with the standard 
format for sending data as part of the VBI lines as specified in the NABTS 
specification (Electronic Industries Association document EIA-516 (May, 1988): 
15 "Joint EIA/CVCC Recommended Practice. for Teletext: North American Basic 
Teletext Specification (NABTS)"). The NABTS specification is hereby incorporated 
by reference. 

Fig. 2 shows a broadcast transmission system 30 for delivering video signals 
fi-om a content provider 32 (e.g., cable headend, television broadcast station, etc.) to 
20 multiple receivers 34, 36. For purpose of this discussion, the broadcast transmission 
system 30 is described in the context of a traditional broadcast television system 
which transmits television signals to many residences. 

The video signals, such as traditional television signals, are distributed over a 
broadcast distribution network. Two example networics are shown in Fig. 2: a 
25 traditional analog VHF or UHF broadcast network 38 and a cable network 40. The 
VHF/UHF broadcast network 38 includes a wireless transmitter 42, in the form of a 
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television tower located at the content provider 32, which transmits the television 
signals 44. A receiver 46, in the form of an antenna located individual residences, 
receives the television signals 44. 

The cable network 40 includes a cable transmitter 48 located at the content 
5 provider 32. The cable transmitter 48 sends signals over a cable distribution structure 
50 (e.g., fiber optic cable, coaxial cable, twisted pair, etc.) to a cable receiver 50 
located at the individual residences. In Fig. 2, the receiver 52 is depicted as a set-top 
box. 

It is noted that other network implementations may be used, such as satellite 
10 communications, RF communication, or a combination of wireless and wire-based 
technologies. 

In the illustrated implementation, two different kinds of display units are 
shown for example purposes. At residence 34, the display unit is embodied as a 
broadcast enabled personal computer 60, or simply '^broadcast PC." The broadcast 

15 PC 60 has a large VGA monitor 62, a processing unit 64, and input devices in the 
form of remote keyboard 66 and remote control handset 68. The remote keyboard 66 
and handset 68 are remotely coupled to the processing unit 64 via a wireless data 
link, such as infrared (IR) or radio (RF). Other types of input devices (e.g., mouse, 
track ball, stylus, etc.) can be used instead of, or in addition to, the keyboard and 

20 handset. 

At residence 36, the display unit is embodied as a set-top box 70 coupled to a 
conventional television 72. A remote control handset 74 is used to remotely control 
the set-top box and television via a wireless data link. In another embodiment, the 
functionality in the set-top box 70 can be incorporated into the television 72. 
25 Content provider 32 is configured to originate the broadcast video signals as 

separate frames containing image data and VBI data. The content provider 32 has an 
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NABTS encoder 80 which encodes VBI data in the conventional 33-byte VBI- 
compatible data packets described in the Background of the Invention section with 
respect to Fig. 1 . 

The content provider 32 also includes a network packet encoder 82 which is 

5 coupled to a data network 84, such as an Ethernet or the Internet. The network 
packet encoder 82 receives a network data packet from the network 84 and converts 
it into a form used by the NABTS encoder 80. The network packet encoder 82 can 
be implemented in software, hardware, or a combination. As one example, the 
network packet encoder 82 can be implemented as a router. 

10 Fig. 3 shows a method for operating the broadcast transmission system 30 to 

carry network data during the VBI interval. This method will be described with 
reference to Figs. 2 and 4-6. 

At step 100, the network packet encoder 80 receives a network data packet 
from the data network 84. As an example, the network data packet is in the form of 

15 * an Internet Protocol (IP) packet Figs, 4 and 5 show an IP packet 120. It has a 
variable-length (N-byte) data payload 122, a fixed-length (A-byte) transport protocol 
header 124, and a fixed-length (B-byte) IP header 126. The data payload 122 
contains the actual network data. The transport protocol header 124 designates the 
transport layer protocols for the data network. Examples of the transport protocol 

20 include Transmission Control Protocol (TCP) and User Datagram Protocol (UDP). 
In Figs. 4 and 5, the BP packet 120 has a UDP header 124 that is eight bytes in length. 

The IP header 126 provides the addressing information necessary to deliver 
the data from source to destination. In this example, it is 20 bytes in length. - ^ 

At step 102 in Fig. 3, the network packet encoder 82 encodes the network data 

25 packet into a variable length data group packet Figs. 4 and 5 show two different 
implementations of step 102 for the example IP packet 120. In Fig. 4, the IP packet 
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120 is encoded into a variable-length data group packet 130. In this implementation, 
the data group packet 130 has a variable-length (M-byte) data block or data payload 
132, a fixed-length (C-byte) type header 134 and a fixed-length (D-byte) reserved 
space header 136. The IP packet 120 is inserted in its entirety (including both 
5 headers) into the data payload 132. 

The fixed-length type header 134 of the data group packet 130 indicates the 
type of data contained in the following data payload 132. In this example, the fixed- 
length type header 1 34 is a two-byte header that is set to 0x08, 0x00 to specify that IP 
data follows. Other data types besides IP data can be specified. For example, to 

10 specify that an ARP packet follows, the type header might contain 0x08, 0x06. 

The reserved space header 136 of the data group packet 130 is specially 
reserved for fiiture usage. In this implementation, the reserved space header 136 is a 
six-byte header particularly suited for storage of the MAC address. As noted earlier, 
the MAC address is used for storing hardware specific information, in particular a 

15 physical hardware address. (See, e.g.. Comer, Douglas E., Internetworking with 
TCP/IP Volume 1, Third Edition, Prentice Hall: Upper Saddle River, New Jersey, 
1995.) Currently, this space is not used because bandwidth is relatively low and 
therefore filtering does not need to be performed at a hardware level. All filtering is 
done in software. When the reserved space goes unused, the six bytes are each set to 

20 0x00. 

The data group packet 130 also has optional padding bits 138 to permit 
encoding of the last portion of the data block 132 into the fixed-size VBI-compatible 
packets, as will be described below in more detail. -^^ 

In the Fig. 5 implementation, the IP packet 120 is encoded into a slightly 
25 different configuration of a variable-length data group packet 140. Here, the data 
group packet 140 has a variable-length (M-byte) data block or data payload 142 and a 
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fixed-length record header 144. The IP packet 120 is inserted in its entirety 
(including both headers) into the data payload 142 of the data group packet 140. 
Padding bits 146 can be optionally used to ensure conformance to the VBI- 
compatible data packet format, as described below. 
5 The record header 144 enables conformation to the record layer defined in the 

NABTS specification. The record header specification was defined when encoders 
were more primitive. This layer is now infirequently, if ever used, in the industry as 
the Bundle Sack Mode (which does not interpret the record format) is used almost 
universally today. To conform to this mode, the network packet encoder 82 attaches 

10 a predefined five-byte record header 144 to the data payload 142. Because this mode 
is not expected to be used for transmission at high bandwidth, no space is reserved 
for the MAC address as is done in the Fig. 4 implementation. 

Each byte of the record header 144 contains four bits (a nibble) b2, b4, b6, and 
b8, and the alternating odd four bits bl, b3, b5, b7 are used as Hamming coded 

15 protection of the four even bits. The first two bytes designate the record type (RT) 
and the record header designator (RD). These types are specified chapter 5 of the 
NABTS specification. The RT and RD bytes are followed by three bytes of address 
space Al, A2, and A3 which specify the format of the data carried in the data 
payload 142. For IP data, the three bytes are specified as Al = 0x8, A2 = 0x0, and 

20 A3 = 0x0. Other fields of the record header that are prescribed in the NABTS 
specification — the record address extension, record link, classification sequence, and 
header extension-field — are^specified-as absent. 

At step 104 of Fig. 3, the NABTS encoder 80 encodes the data group packet 
130, 140 output firom the network packet encoder 82 into one or more fixed-length 

25 (33-byte) VBI-compatible data packets 20. As described in the Background of the 
Invention, each VBI-compatible data packet 20 has a data block 22 and a five-byte 
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header 24. More particularly, the data group packet 130, 140 is partitioned into 26-, 
27-, or 28-byte segments and inserted into the data block 22. The padding bits 138, 
146 ensure that the data group packet 130, 140 fits evenly into the 28-byte data block 
22. The header 24 consists of three packet address bytes PI, P2, P3, one continuity 
5 index byte CI, and one packet structure byte PS. 

With respect to step 104 of the Fig. 3 method, the two different data group 
packets 130, 140 are treated as NABTS-compatible. variable-length data group 
packet as prescribed by chapter 4 the NABTS specification. These data group 
packets are segmented into the VBI-compatible data packets 20 according to well- 

10 known, conventional techniques defined in the NABTS specification. 

It is noted that the network packet encoder 82 and NABTS encoder 80 can be 
implemented in hardware, software, or a combination hardware/software. In 
hardware, the network data packet is initially placed in a register. The appropriate 
headers are added to form the data group packet, which is then stored in another 

15 register. The data group packet can be passed to a shift register in the NABTS 
encoder 80 where it is shifted out 33-bytes at a time to form the VBI-compatible data 
packets 20. In a software implementation, the network data packet is cached in 
memory, where the appropriate headers are later added. The software then segments 
the information into the VBI-compatible data packets. 

20 At step 106 of Fig, 3, the VBI-compatible data packets 20 are transferred to 

the appropriate transmitter (e.g., tower transmitter 42 or cable transmitter 48) and 
broadcast over the broadcast medium as part of VBI within the analog television 
signal. The individual residences 34, 36 are equipped with a receiving unit (e.g., 
antenna 46, set-top box 70, etc.) to receive the VBI-compatible packets 20 from the 

25 broadcast distribution medium (step 108 of Fig. 3). The 33-byte data packets are 
transferred to a decoding unit. 
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Fig. 6 shows a receiving and decoding unit 150 in more detail. It includes a 
receiver board 152 which receives the VBI-compatible packets 20 of the analog 
television signal. The receiver board 152 can be configured as part of the tuner 
which is capable of tuning to a specified channel. In one implementation, the 
5 receiver board 152 is configured to perform Forward Error Correction (FEC) and 
data packet re-assembly, as well as other functions specified in Chapter 3 of the 
NABTS specification. 

A miniport driver 154 and layered miniport driver 156 are coupled to receive 
the VBI-compatible packets 20 fi-om the receiver board 152. In the illustrated 
10 example, the drivers are VBI network interface card (NIC) drivers that comply with 
the Network Device Interface Specification (NDIS) 4.0, as represented by interface 
layer 158. In one implementation, the layered miniport driver 156 is a layered 802.3 
miniport driver. These drivers support the VBI extensions defined in the NDIS 
document. The VBI NIC drivers 154, 156 perform the following three functions: 
15 1. Connection management via the NDIS library using special VBf Object 

IDs and a VBI media type; 

2. Data I/O via the NDIS library (NDIS.SYS); and 

3 . Support for UDP/EP multicast packets. 

Additionally, if the hardware level receiver board 152 does not support the 
20 functionality defined in the NABTS specification, the device drivers may also 
perform the forward error correction and data packet re-assembly as specified in 
NABTS specification at Chapter 3. 

Packet re-assembly, whether performed in hardware at receiver board 152 or 
software at the miniport drivers 154, 156, consists of first reconstructing the data 
25 group packet 130, 140 from the fixed-length VBI-compatible packets 20 (step 110 of 
Fig. 3). After the data group packet is recovered, the network data packet (e.g., IP 

13 
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15 



20 



packet 120) is extracted from the data payload of the data group packet (step 1 12 of 
Fig. 3). If the data group packet is in the format of the Fig. 4 implementation, the 
type header is initially read to identify what type of network data is contained in the 
data payload before proceeding to the data extraction step. 

Once the network data packet is extracted, it is ready for use by the 
application. In the Fig. 6 embodiment, the network packet is an IP packet which is 
passed to the network protocol software interface. Typically, this software interface 
supports both TCP (Transmission Control Protocol, a reliable two way transmission 
method) and UDP (User Datagram Protocol, a unidirectional, non-guaranteed method 
of sending data). In the case of IP data transmitted in the VBI, the client accepts IP 
data using the UDP software interface 160, which performs some rudimentary error 
checking (e.g., CRC) and filtering. At this point, the IP packet is in order to be 
handled by the Winsock layer 162, a software implemented interface which complies 
with the Windows Sockets Specification. The Windows Sockets Specification 
defines a well known standard set of APIs that provide a network independent way to 
send and receive data. An application 164 uses the IP data packets through various 
API calls orchestrated through the Winsock layer 162. 

This invention is beneficial in that it prescribes a technique for transmitting 
network data over the VBI without losing its known format. A computer application 
at the recipient can use standard APIs, such as those prescribed by the Windows 
Sockets Specification, to use the network data. 

In compliance with the statute, the invention has been^described inJanguage 
more or less specific as to structural and methodical features. It is to be understood, 
however, that the invention is not limited to the specific features described, since the 
means herein disclosed comprise preferred forms of putting the invention into effect. 
The invention is, therefore, claimed in any of its forms or modifications within the 
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proper scope of the appended claims appropriately interpreted in accordance with the 
doctrine of equivalents. 



/r 
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CLAIMS 

1. A method for encoding Internet Protocol (IP) data into a format for 
transmission as part of Vertical Blanking Interval (VBI) of a broadcast video signal, 
comprising the following steps: 

5 receiving an IP packet having an IP data block and header information; 

encoding the IP packet into a variable-length data group packet having a data 
block and header information so that the data block of the data group packet 
comprises the IP packet; and 

encoding the variable-length data group packet into one or more fixed-length 
10 VBI-compatible packets, each VBI-compatible packet having header information and 
a data block comprising at least a portion of the data group packet. 

2. A method as recited in claim 0, further comprising the step of 
configuring the data group packet with a 6-byte first header and a 2-byte second 

15 header. 

3, A method as recited in claim 0, further comprising the step of 
configuring the data group packet with a fixed-length reserved space header and a 
fixed-length type header indicating that the variable-length data block contains IP 

20 data. 

4, A method as recited in claim 0, further comprising the step of 
configuring the data group packet with an NABTS-compatible record header. 
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5. A method as recited in claim 0, further comprising the step of 
transmitting the fixed-length VBI-compatible packets. 

6« A transmission medium carrying the fixed-length VBI-compatible 
5 packets constructed according to the steps in the method as recited in claim 5, 

7, A storage medium storing the variable-length data group packet 
constructed according to the steps in the method as recited in claim 0. 

10 8. A computer programmed to perform the steps of the method as recited 

in claim 0. 

9. A computer-readable memory which directs a computer to perform the 
steps of the method as recited in claim 0. 

15 

10. A method for encoding Internet Protocol (IP) data for broadcast 
transmission, comprising the following steps: 

receiving an IP packet having an IP data block and header information; and 
inserting the IP packet as a data payload of an NABTS-compatible, variable- 
20 length data group packet. 

11. A mfithod .as recited - in claim 10, _fiirtlier comprising the step of 
configuring the data group packet with a 6-byte first header and a 2-byte second 
header. 

25 

/1 
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12. A method as recited in claim 10, further comprising the step of 
configuring the data group packet with a fixed-length reserved space header and a 
fixed-length type header indicating that the data payload contains IP data, 

5 13, A method as recited in claim 10, further comprising the step of 

configuring the data group packet with an NABTS-compatible record header. 

14. A storage medium storing the variable-length data group packet 
constructed according to the steps in the method as recited in claim 10. 

10 

15. A computer programmed to perform the steps of the method as recited 
in claim 10. 

16. A computer-readable memory which directs a computer to perform the 
15 steps of the method as recited in claim 10. 

17. A method for encoding Internet Protocol (IP) data for broadcast 
transmission, comprising the following steps: 

receiving an IP packet having an N-byte IP data block, an A-byte transport 
20 protocol header, and a B-byte IP header, 

constructing a variable-length data group packet having an M-byte data 
payload, a C-byte-xlata type header, ania D-byte reserved space header; 

inserting the entire N+A+B-byte IP packet into the M-bytc data payload of the 
data group packet; and 
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encoding the variable-length data group packet into one or more fixed-length 
VBI-compatible packets, each VBI-compatible packet having header information and 
a data block comprising at least a portion of the data group packet. 

18. A method as recited in claim 17, wherein the C-byte data type header 



19. A method as recited in claim 1 7, wherein the A-byte transport protocol 
header comprises 8 bytes and the B-byte IP header comprises 20 bytes. 

20* A method as recited in claim 17, wherein the NABTS-compatible, 
variable-length data group packet is also constructed with a trailer of one or more 
padding bytes. 

21. A storage mediiun storing the variable-length data group packet 
constructed according to the steps in the method as recited in claim 17. 

22. A computer programmed to perform the steps of the method as recited 
in claim 17. 

23. A computer-readable memory which directs a computer to perform the 
steps of the method as recited in claim 17. 



comprises 2 bytes and the D-byte reserved space header comprises 6 bytes. 




I 
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24. A method for encoding Internet Protocol (IP) data for broadcast 
transmission, comprising the following steps: 

receiving an IP packet having an N-byte IP data block, an A-byte transport 
protocol header, and a B-byte EP header; 
5 constructing an NABTS-compatible, variable-length data group packet having 

an M-byte data payload and a fixed-size record header; and 

inserting the entire N+A+B-byte IP packet into the M-byte data payload of the 
NABTS-compatible data group packet. 

10 25. A method as recited in claim 24, wherein the NABTS-compatible, 

variable-length data group packet is also constructed with a trailer of one or more 
padding bytes. 

26. A storage medium storing the variable-length data group packet 
1 5 constructed according to the steps in the method as recited in claim 24. 

27. A computer programmed to perform the steps of the method as recited 
in claim 24. 

20 28. A computer-readable memory which directs a computer to perform the 

steps of the method as recited in claim 24. 

29, A method for encoding a computer network data packet for 
transmission as part of a Vertical Blanking Interval (VBI) of a broadcast video signal, 
25 comprising the following steps: 

adding a header to the network data packet to form a data group packet; and 
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encoding the data group packet into one or more fixed-length VBI-compatible 
packets. 



30. A method as recited in claim 29, wherein the header is a type header 
5 indicating a type of data contained in the network data packet. 

31. A method as recited in claim 29, wherein the header is an NABTS- 
compatible record header. 

10 32. A method as recited in claim 29, further comprising the step of 

transmitting the fixed-length VBI-compatible packets, 

33. A method as recited in claim 29, wherein the adding step comprises the 
step of adding a 6-byte first header and a 2-byte second header to the network data 

15 packet. 

34. A method as recited in claim 29, wherein the adding step comprises the 
step of adding a fixed-length reserved space header and a fixed-length type header 
indicating a type of data contained in the network data packet. 

20 

35. A storage medium storing the VBI-compatible packets constructed 
according to the-steps in the method as recited in claim 29. 

36. A computer programmed to perform the steps of the method as recited 
25 in claim 29. 
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37. A computer-readable memory which directs a computer to perform the 
steps of the method as recited in claim 29. 



10 



15 



20 



38. A method for decoding computer network data received as part of a 
Vertical Blanking Interval (VBI) of a broadcast video signal, comprising the 
following steps: 

receiving multiple fixed-length VBI-compatible packets; 

reconstructing a variable-length data group packet from the fixed-length VBI- 
compatible packets, the data group packet having a header and a variable-length data 
block containing the network data; 

reading the header of the data group packet to identify a type of data contained 
in the data block of the data group packet; and 

extracting the network data from the data block of the data group packet. 

39. A computer programmed to perform the steps of the method as recited 
in claim 38. 

40. A computer-readable memory which directs a computer to perform the 
steps of the method as recited in claim 38. 

41. A broadcast transmission system for distributing video signals firom a 
distributor to a receiver, comprising: 

an encoding unit at the distributor to encode a computer network data packet 
into a Vertical Blanking Interval (VBI) compatible packet, the encoding unit adding a 
header to the network data packet to form a variable-length data group and encoding 
the group packet into one or more fixed-length VBI-compatible packets. 
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a transmission unit coupled to receive the VBI-compatible packets from the 
encoding unit, the transmission unit transmitting the VBI-compatible packets over a 
distribution medium; 

a receiving unit at the receiver to receive the VBI-compatible packets from the 
5 distribution medium; and 

a decoding unit coupled to the receiving unit to reconstruct the variable-length 
data group packet from the fixed-length VBI-compatible packets and extract the 
network data packet from the data group packet. 

10 42. An encoding unit for encoding a computer network data packet for 

transmission as part of a Vertical Blanking Interval (VBI) of a broadcast video signal, 
comprising: 

means for adding a header to the network data packet to form a data group 
packet; and 

15 means for encoding the data group packet into one or more fixed-length VBI- 

compatible packets. 

43. A receiving unit for decoding computer network data received as part 
of a Vertical Blanking Interval (VBI) of a broadcast video signal, comprising: 
20 a receiver to receive multiple fixed-length VBI-compatible packets; 

a device driver coupled to the receiver; 

one of the receiver or device driver being-configured to reconstruct a variable- 
length data group packet from the fixed-length VBI-compatible packets, the data 
group packet having a header and a variable-length data block containing the network 
25 data, said one of the receiver or device driver being further configured to extract the 
network data from the data block of the data group packet 

^3 
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44. A computer-readable memory having a network packet structure that 
can be encoded into fixed-length NABTS-compatible data blocks for transmission as 
part of a Vertical Blanking Interval (VBI) of a broadcast video signal, the network 
packet structure comprising: 

a variable-length data block encapsulating network data and header 
information for the network data; 

a first header to the data block, the first header indicating a type of network 
data contained in the data block; and 

a second header to the data block, the second header comprising reserved 
space for subsequent definition by a user. 

45. A computer-readable memory as recited in claim 44, wherein the fixst 
header is two bytes and the second header is six bytes. 
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